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SIR: 

DECLARATION UNDER 37 CFR 81.131 

In association with the filing a reply to a Final Office action dated March 31 , 
2006, applicants are submitting for acceptance by the Examiner this Declaration under 
Rule 131 to antedate the Challener et al. reference cited by the Examiner in the 35 USC 
§ 102(e) rejections. 

Indeed, in accordance with Rule 131, applicants declare the following to provide 
a showing of "conception of the claimed invention prior to the effective reference date, 
and due diligence at least from immediately prior to the effective date of the reference 
until a subsequent reduction practice or the filing of a patent application". In particular, 
applicants declare the following: 
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• The effective date of the Challener et al. reference, US Patent 6,08 1 ,793, is the 
US filing date of December 30, 1997; 

• Applicants' conception of the claimed invention occurred prior to February 
24, 1997, as evidenced by Attachment A, an email (dated 4 March 1997 ^ and 
attachment from inventor Stuart Stubblebine to the AT&T patent division 
requesting a patent to be filed on the attachment that was * presented at the 
Financial Cryptography Conference on 24 Feb. 1997"; 

• Applicants applied due diligence toward a reduction to practice of the present 
invention (at least immediately prior to the effective date of December 30, 
1997), as evidenced by Attachment B, the front page of US Patent 6,108,644, 
which is the parent application to the present application, denoting the filing of 
parent application (Serial No. 09/025,802) on February 19, 1998; and 

• Applicants provided a constructive reduction to practice by the filing of the 
subject application on August 11, 2000, as a continuation of the above-noted 
parent application, as evidenced by Attachment C, a copy of the filing receipt 
for this application. 

Based on the above declarations, applicants thus assert prior conception and diligent 
reduction to practice of the present invention sufficient to antedate the Challener et al. 
reference. Applicants thus request the Examiner to remove this reference as applicable 
to this application. 



Respectfully submitted, 
David M. Goldschlag et al. 




Attorney for applicants 
610-346-7112 

Date: U \ U j $Cp 
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mailbox:/C%7C/Mail/lnbc,..arch.attxom&num^p482 maiIbox:/C%7C/Mail/I^ 

Subject: new patent work f^ttcichmtrrt /) 

Date: Tue, 4 Mar 1997 17:24:21 +0500 

From: "Stuart Stubblebine" <stubblebine@research.att.com> 

Reply-To: stubblebine@research.att.com 

To: samuelh@mail.att.net 

CC: mar@research.att.com, dpm@research.att.com 



I'm following up on a recent discussion we had on patenting some work 
I did with two government employees at the Navel Research Lab. It 
appears now that it would be beneficial for this work to be 
submitted through the AT&T patent process. The work was presented 
at the Financial Cryptography Conference on 24 Feb. 1997. The paper 
is titled" Serial Unlinkable Transactions". This work was of 
considerable interest to an employee at Encyclopedia Britanriica. They 
are interested in prototyping the technology for possible integration 
into their on-line service offering. (My co-authors/inventors plan 
to follow up with him on this activity. ) 

Our secretary, Marion Riley, is sending a copy of the papers 
and slides. 

Thanks, 

Stuart Stubblebine 

Stuart Stubblebine stubblebine@reseaich.att.com 
AT&T Research, 2A-345A voice: 908-582-5481 

600 Mountain Ave., Murray Hill, NJ 07974 fax: 908-582-5192 
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Unlinkable Serial Transactions 
(FC97 Preproceedings Draft) 

Paul F. Syverson Stuart G. Stubblebine 

syverson@itd.nrl.navy.mil stubblebine@research.att.com 

David M. Goldschlag 
goldschlag@itd.nrl.navy.mil 

Abstract 

We present a protocol for unlinkable serial transactions suitable for a variety of network-based sub- 
scripts servaces. The protocol prevents the service from tracking the behavior of its customers while 
protecting the service vendor from abuse due to simultaneous or "cloned" usatce from a ringle subscrip- 
tion We present variants of the protocol supporting pay-per-use transactions within a subscription. 
We describe other applications including contracting out subscription management, multi vendor package 
sales, proof of group memberslrip, and voter registration. 

1 Introduction 

This paper is motivated by an apparent conflict of interest concerning the privacy of information in an 
electronic exchange. Commercial service providers would like to be sure that they are paid for their services 
and protected from abuse due to simultaneous or "cloned" usage from a single subscription. To this end 
they have an interest in keeping a close eye on customer behavior. On the other hand customers have an 
interest in the privacy of their personal information, in particular the privacy of profiles of their commercial 
activity. One well known approach to this problem is to allow a customer to register with vendors under 
pseudonyms one for each vendor [3]. By conducting transactions using anonymous electronic cash f e-cash) 
the customer s anonymity is maintained. But, the vendor is able to protect his interests by maintaining a 
profile on each of his anonymous customers. 

In this paper we present effecTivily the op^ customer may be known to 

the vendor, but his behavior is untraceable. This would appear infeasible. If transactions cannot be linked 
to the customer, what is to keep him from abusing the service? For example, if someone fails to return a 
rented video, the video rental company would like at minimum to be sure that this person cannot rent any 
more videos. But, the company cannot do this if they cannot determine who the renter is 1 We will present 
a protocol that makes transactions unlinkable but protects vendors from such abuses. 

For the near future at least, a large part of the market on the Internet and in other electronic venues will 
rely on credit card based models (such as SET [16] or Cybercash [6] or simply Mending credit card numbers 
ZZ 5/" AppllCat \ ons four Protocol that require payment are not dependent on the payment mechanisms 
used. Thus, our protocol can be easily applied now but is equally amenable to use with e-cash. Even in an 
environment in which pseudonyms and anon ymous e-cash are generally available vendor profiles of customers 

mechanism, to malce this difficult [4]. Thu s> the interests of the vendor can he protected. 



PACE 11/44 * RCVD AT 6/6/2006 9:54:59 AM [Eastern Daylight Time] * SVR:USPTO-EFXRF-5/18 * DNIS:2738300 * CSID:610 346 8189 * DURATION (mm-ss):15-44 



BEST AVAILABLE COPY 



Jun 06 06 09:57a 



uuendy ui koba esq 



610-346-8189 



p. 12 




2 



(or their pseudonyms) might be undesirable because the customer's anonymity protection has a single point 
of failure. If the vendor is ever able to link a pseudonym to a customer, i;he entire profile immediately 
becomes linked to that customer. In our solution, if a customer is ever linked to a transaction, only his link 
to the one transaction is revealed. (This is somewhat analogous to the property of perfect forward secrecy 
in key establishment protocols.) 

On what applications could our approach be used? Consider a subscription service for an on-line news- 
paper or encyclopedia. Customers might have an interest in keeping the searches they conduct private. At 
the same time, vendors would like to make it difficult for customers to tramrfer their ability to access the 
service. This will serve as our primary example. 

We will also consider other applications. One example is pay-per-use service within a subscription (e.g., 
Lexis-Nexis or pay-per-view movies available to cable TV subscribers). Unlmkable serial transactions can 
also be used to provide multivendor packages as well as ongoing discounts. And, they can be used for 
anonymous proof of membership for applications having nothing directly to do with electronic commerce. 
Applications include proof of age and proof of residency. They can also be used to construct a simple voter 
registration protocol. 

The paper is organized as follows. In section 2 we describe related work. Most of the basic mechanisms on 
which we rely come from work on e-cash; although, we are able to greatly simplify some of those mechanisms 
for our purposes. We describe these and their relation to our work. We also rely on the assumption that 
communicating parties will not be identified by the communications medium, independent of the messages 
they send. Services that prevent this are discussed as well. In section 3 we will describe the basic protocol 
including set up, usage, and termination of a subscription. We also discuss recovery from broken connec- 
tions. In section 4 we describe various applications of unlmkable serial transactions and associatied protocol 
variants. In Beet ion 5 we present concluding remarks. 



2 Related Work 



2.1 Digital Cash 

Digital cash, especially anonymous e-cash as presented by Chaum et al. [5], iti characterized by several re- 
quirements [12]: independent of physical requirements, unforgeable and uncopyable, untraceable purchases, 
off-line, transferable, and subdividable. No known e-cash system has all of Uhese properties and certain 
properties, especially e-cash that can be divided into unlinkable change, tend to be computationally expen- 
sive. 



E-cash can either be on-line or off-line In an on-line scheme, the vendor can verify with a bank that the 
cash has not previously been used before completing the transaction. In an off-line scheme, double spending 
must be detectable later, and the identity of the double spender must then be revealed. Previously agreed 
upon penalties can then be applied that make double spending not cost effective. 

Chaum 's notion of blinding [4] is a fundamental technique used in anonymous e-cash and assigning 
pseudonyms. A bank customer may want a certain amount of e-cash from the bank, but may not trust the 
bank not to mark (and record) the e-cash in some way. One solution is for th«; bank to sign something for 
the customer that the bank cannot read, while the customer presents the bank with evidence that the bank 
is signing something legitimate. 

Chaum's blinding depends on the commutativity of modular multiplication operations. Therefore, the 
customer can create an e-cash certificate, multiply it by a random number called a blinding factor. If the 
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bank signs the blinded certificate, the customer can then divide out the blinding factor. The result is the 
unblmded certificate signed by the bank. But the bank does not know what it signed. 

How can the customer assure the bank that the blinded certificate is legitimate? In Chaum's scheme 
the customer presents the bank with many blinded certificates that differ in serial number, perhaps, but not 

L oXTim ' ? T k , ChOOSeS tb l ' lt WUl 8igD -Dd Mkfi the CUflton,er for the blinding factors of 
« t ^. tauaan ^. cho ^ cerbficates turn out to be legitimate when unblinded, the bank can have 
confidence that the remaining blinded certificate is legitimate too. 

One on-line e-cash scheme is presented in [15]. To obtain an e-cash certificate that only he can use a 
T^Z Pte tt n V bank with a hash of a random number. The bank signs an e-ca*h certificate linkmg 
that hash with a denomination. To use the e-cash, the customer reveals the random number to a vendor 
who m turn takes the e-cash to a bank. Since hashes are one-way function*, it would be very hard for 
someone other than the customer to guess the secret that allows the e-cash to be spent. After the money is 
spent the bank must record the hash to prevent it from being spent again. This scheme can be combined 
with blinding, to hide the actual e-cash certificate from the bank during withcjawal. 

One off-line e-cash scheme is presented in [9]. There, the bank signs bunded certificates. To spend the 
c-cash the customer must respond to a vendor's challenge. The response can be checked by inspecting the e- 
cash. Double spending is prevented because the challenge/response scheme is constructed so the combination 
of responses to two different challenges reveals the identity of the customer. As long as the customer does not 

22 "tamed foible s^di^ ^ ^ ~ ^ ™*°™»> " «» 

It may be the case that truly anonymous unlinkable e-cash enables criminal activity. Several key escrow 
auSzSion^ ^ developed that can reveal identities to authorities who obtain proper 

Our notion of unlinkable certificates came from asking the following question: what else shares some of 
the features of d. g .tal cash? Unlinkable certificates share many of these features: they must preserve 
user a anonymity and not be traceable, but they must protect the issuer and not be forgeable or copyable 
£ l ' TV' 'f^f^y is not de ««ble. We use hashing of random numbers and bunding 
41 Z r PmeR t U ? llnkable certificates. Our unlinkable certificates differ from Chaum's pseudonym! 
[4] which are an alternate to a universal identification system. Each pseudonym is supposed to identify 
its owner to some institution and not be linkable across different institutions. Unlinkable serial certificates 
are designed to be unlinkable both across institutions and across transactions within a single institution In 

7 T 7f T' S "I" n' *?. 66 ^ aWe *° Hnk traneactions *<> a single customer, even if that customer 
had to identify himself m.tially (i.e., during the subscription process). At the same time, the vendor needs 
to be able to protect himself against customers that abuse his service. 

Our blinding also differs from the usual approach. Typically some mechanism is necessary to assure either 
the 1S sumg bank or receiving vendor that the certificate blindly signed by the issuer has the right form i e 
that the customer has not tricked the signer into signing something inappropriate. We described ChaunVs 
basic approach to domg this above. By moving relevant assurances to other pcrts of the protocols, we are 
able to eliminate the need for such verification. The result is a great simplification of the blinding scheme 



2.2 Anonymity Services 



ex^X vlir, P , ,iY tC mt0rmatl0n Private if communication channels reveal identities? For 

tLT„lr?h K K nS , fCC nUml J er8 Can SUb8Cribe t0 ServiceS that reveai callel8 ' P h °«* numbers to 
the vendor thereby obviating any pseudonym the customer may be using. A similar service in the form of 
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caller-id is now available to many private customers. If a communication channel implicitly reveals identities 
how can customer s private information be protected? ' 

The solution lies in separating identification from connections. The connection should not reveal infor- 
mation. Identifying information should be carried over the connection. (Of course, vendors and private 
parties are welcome to close connections that do not immediately provide sufficient identifying information ) 
On the Internet, dependmg upon ones environment and threat model, several solutions exist. 

For e-mail, anonymous remailers can be used to forward mail through a service that promises not to 
reveal the sender's identity to the recipient. User's worried about traffic analysis can use Babel [11] or other 
Mixmuter [7] based remailers which forward messages through a series of Cbaum mixes [31. Each mix can 
identify only the previous and next mix, and never (both) the sender and recipient. 

For Web browsing, the Anonymizer [1] provides a degree of protection. Web connections made through 
the Anonymizer are anonymized. By looking at connection information, packet headers.etc. the destination 
Web server can only identify that the connection came from (through) the Anonymizer. 

Onion routing [17, 14, 10] provides anonymizing services for a variety of Internet services over connections 
that are resistant to traffic analysis. Like Babel, onion routing can be used for e-mail. Onion routing can also 
be used to hide Web browsing, remote logins, and file transfers. If the communicating parties have secure 
connections to endpomt onion routers, communication can be anonymous to both the network and observers 
but the parties may reveal identifying information to each other. The goal of onion routing is anonymous 
connections, not anonymous communication. Other application independent systems that complicate traffic 
analysis in networks have been designed or proposed. In [8] a cryptographically layered structure similar to 
onions m onion routing is used to forward individual IP packets through a network, essentially building a 
connection for each packet in a connectionless service. In [13], mixes are used to make an ISDN system that 
hides the individual within a local switch originating or receiving a call. 



3 Transaction Unlinkability 

In this section we describe protocols that prevent linking of a client's transactions to each other. Conse- 
quently, they also cannot be linked to the client himself. We assume that the client has subscribed to a 
service with whom he will conduct these transactions and has provided adequate identifying and billing 
information (e.g., credit card numbers). The protocols make use of many basic e-cash primitives but are 
generally much simpler than protocols using these primitives in their more common applications. 

The basic protocol allows a customer to sign up for unlimited use of some subscription service for a period 
of time but prevents the service from "determiiing w'hen hi has" used "the service or what he has accessed At 
the same time, mechanisms are provided that make it difficult for the customer to share his subscription with 
others and leaves him vulnerable to detection if he should do so. Next we introduce a simple protocol for 
electronic tokens. This protocol can be incorporated into the basic protocol to accommodate subscriptions 
that include the possibility of pay-per-use transactions. 



3.1 Basic Unlinkable Serial Protocol 

In this protocol we begin with the assumption that the customer has adequately satisfied the vendor to 
° AT *" account T f, at ls - he has Provided the vendor with sufficient proofs of identity, cash, proofs of 
creditworthiness, etc. We assume that the customer has an associated identifier C for the account, whether 
or not his identity is actually known by the vendor. (He may in fact have different identifiers for different 
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^counts.) We assume that he also has at this point an associated signature key for his account, (We 
use square braces to indicate digital signatures and curly braces to indicate encryption. Thus, '[X} K > refers 

between WV^ * TU^H'^ 8 *° * ^ ^ K ' N ° <***°V*&* Nation 

between, e.g., Ay m {X} Kv and K v l in [X] K -> is assumed. We use over-lining to indicate blinding: e.g., 

'X' refers to the result of blinding X, for use with the appropriate signature key.) 

3.1.1 Initially Obtaining Service Certificates 

Message 1 C V : [Request for certificate of type S, C, hfNij^ -> 



Message 2 V ->■ C : [h(Ni)] K;l 

The signature key used here by the vendor is assumed to be used only for signing such certificates. It 
is also subject to periodic renewal. Service signature keys have a published expiration time. All certificates 
u°a a u Ta ° r eXcha ?f? b * that time - We wiU «* ^at there is no need to verify the structure of the 
certificate n ° nCe ' diCnt 8,,bstitutes anvthin 8 inappropriate the .esult can only be an invalid 

When the customer wants to make use of the service, he conducta the following protocol with V. 

3.1.2 Redeeming Certificates and Obtaining New Ones 

Message 1 C > V : {Request for transaction of type S, [M^Mjfj ' . W, K C v)k v 

Message 2 V -+ C : {Approved OR Not appnved OR Audit} Kcv 

Message 3 C -» V : {h(N i+1 )} Kov 

Message 4 V -»• C : [A(^ f+1 )) Ji ._ 1 

Message 5 C -> V : {Ack h(N i+l )) Kcv 

Message 6 C V : {Transaction}^,, 

Here K cv is a key that is used to protect the integrity of the session. If the response in message 2 is Not 
approved, e.g., if the certificate was previously used or is not of valid form, then the protocol terminates. 

3.1.3 Audit and Not approved 

If the response is Audit then a special audit occurs in which C must present some proof of identity within 
a short period of time. If this i B satisfactory, a new certificate is issued. If it is not satisfactory or if C does 
not comply then the protocol terminates, and the certificate is logged along with a note that it was used 
during a failed aud.t. In either case, no transaction takes place so that audited customers axe not linked to 
specific transaction requests. The main purpose of audits here is to serve as a secondary deterrent to sharin K 
a subscription with a nonsubscriber. (The primary deterrent is the inconvenience of passing the certificate 
back and forth between those sharing as compared with the cost of obtaining another subscription itself.) 

By exercising the audit check frequently or at strategic times, the vendor can iearn both the client's usase 
frequency and patterns. This might allow the vendor to correlate later transactions (and possibly earlier 
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transactions) with the particular client. The client might counter this limitation by employing a masking 
scheme on top of the basic protocol. However, this can considerably increase the load on the subscription 
service. Clients might also counter such vendor analysis by delaying ordinary transaction requests for a 
random amount of time following an audit. This places no extra burden on the subscription service but may 
cause customers inconvenience substantially beyond that of audits themselves. Since audits are a secondary 
deterrent to abuse, they might be conducted infrequently. The tradeoffs between threats to anonymity and 
the deterrence affect on subscription sharing are difficult to assess a priori. Thus, exactly how frequent to 
make audits is currently difficult to say. 

Notice that if a customer is ever caught during an audit having given away his certificate, he effectively 
forfeits his subscr.pt.on. This is because that certificate can never be used aj;ain, and no new certificate is 
issued to continue the subscription. Off-line appeal mechanisms may be available for customers who for 
example, lose certificates or secret nonces. 

The response to a request for service might be Not approved for a number of reasons. These include 
that the nonce does not match the submitted certificate and that the certificate is not valid for the service 
requested. Alternatively, the certificate submitted might use an expired key. If the client is a valid subscriber 
who never received an initial certificate for the current key, this should be reflected in the vendor's records 
The client can then get an initial certificate in the usual manner. Off-line appeal will again be necessary for 
clients who feel they have been refused a legitimate transaction request. 

3.1.4 Recovering from Broken Connections 

We will consider connection breaks occurring from the end of the protocol to the beginning. If a. connection 
breaks after a new certificate has been acknowledged (message 5), the client can simply initiate a new 
transaction with the new certificate. If a connection breaks after C receives message 4 but before V receives 
message 5, the client can again simply initiate a new transaction. (If the connection is not actually broken 
but V did not receive message 5, V will refuse to process any request from C (i.e., message 6) until C sends 
him an acknowledgement.) 

Before this point in the protocol the client will not yet have received a new certificate. So, recovering from 
any connection breaks that occur prior to this point in the protocol will involve replaying the protocol The 
vendor should keep a record of each protocol run until he receives the acknowledgement in message 5. When 
reestablishing a connection C should inform V that this is an attempt to reestablish a broken connection 
and then replay the protocol exactly, except that each replayed message should contain a field inside the 
encryption indicating that it is a reconnect message. (Should more than one attempt be made to reconnect 
this field must indicate which attempt it is, i.e., second, third, etc.) V should abort the protocol if any of 
the message fields differ from the.previous connection (other., than. by. the reconnect .field). If the connection 
breaks after V has sent an Audit in message 2, V should keep a record of the protocol run even if C properly 
identifies himself upon reestablishing the connection. It may be that a cheater broke the connection and 
then qu.ckly notified the legitimate client of the audit. The vendor will need to decide what to do eg if 
several such breaks have been logged for a given G at exactly that point in transactions. 

Notice that the customer need never identify himself when a broken connection occurs (unless an audit 
had already been stipulated by the vendor). Thus, he need not worry about being associated with a given 
transaction. Even his attempt to reconnect following a connection break in a run where a specific transaction 
request was made cannot be associated with that request. This is because the actual transaction occurs after 
a new certificate is issued. And, if a connection were to break after a new certificate was issued, he would 
initiate a reconnection using the new certificate. 
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3,2 Service Key Management 

For unlinkable protocols to work, it is important that authorization keys are not "closely" associated with 

fZT E^i^S ' Z u 11 ^ ^ thG Vend ° r to be able to uni ^ l y ass " ciat * * service key with each 
client, which would enable the vendor to associate transactions with clients. 

3.2.1 Committing to Service Keys 

A straightforward technique to overcome this vulnerability requires the vendor to publicly commit to all 
S^rS^l »T' .T 1118 ^ I" , aChiCVed by Publi8hin « "Nation, at regular intervals, at a unique 
S T 7% ° 1,046111,31 cUentS ° f the 6ervke - An examp,e Publication format for each service 

consists of the serv.ee type, expiration time, and signature confirmation key lor signatures associated with 
this service, together with a one-way hash of these. 

3.2.2 Subscription Termination 

Other than as a general security precaution, the primary reason to change service keys is to facilitate 
expiration of subscriptions. When keys expire, our only current mechanism ia to have clients obtain new 
Z^l H ff JU . " " t Wh t n S i gDiDg UP f ° r * 8erVice initially - Service Ration can be structured in 
mSl fmelfTr; ^ ^ ™ disad ™ ta ^- We will present some of these and briefly 

Td con t .rV \h ^- Ch 18 m0St ^ t&ble wiU de P end on particular aspects of application 

;:iTZ£;^r es of discussion let us - ume that the sm ^ d - «. 

3.2.3 Subscription Expiry 

£v« ST i8 40 haTO . ann "'^ Bed ke * s that st art each month. In other words, there are twelve valid service 
keys for the same serv.ee at all times. This is convenient for the customer and similar to existing subscription 
ZtT™'' TT !l paftitions those *** * twelve groups, reducing the LonymJy of 

SSTLTSSf* ^ wTt* bC 3 Pr ° blem - * Ascriptions annualLd to quarters Ls 
J K ■ ♦ .^onymity, but this might stUl be unacceptable. And, it reduces customer flexibihty 
about when subscriptions can begin. ' 

when n thI^ r s u a £ Ve {f t0 -I mODthI ^^ g° od i° r *" 8 ubs C ribers,Sub S cribers obtain twelve seed certificates 
1 Z I J SUbscribe ' °° e use u m , each ™ Dth of ^e succeeding year. This does not reduce anonymity 
as the last option d.d. On the other hand, it requires that customers keep track of the multiple certificates 

2 ^t3atXuTt g b2n T' 1 ? ^7™ ° f th6ir PCri * d ° f e,i « ibilit ^ ^™ the vendoifpS; l C t^ 
MaS; •? S 5 . mUCh r . edUCed SmCe a wiU l0Se at most current month's certificate 

d^rri^d^ Thus, t heinconvenience 

the h^l^'r^^fi 0 aU snb t T ipti ° QS end m the 8ame mont h. Someone subscribing at other than 
to * W ° U uf Pay a Pr ° rated amount for hi6 sub8cri Pt Th " ^oids reductions 

AnXr IkaS J T f ?K 8 " ' " CUSt ° mer fleXibUity iD ch ° 0Sin S th<! endin S of th ° subscription 

^ tl 4^ ^ 86 ? , aP TT h 15 tHat Bub8C "P tion r — ' » "ow all concentrated at one point 
?h^w n I l!? g eXtremdy ""balanced load on the part of the system handling sign up and renewal. 
This would probably remain true even if renewing customers were allowed to renew m advance. It could be 
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diminished by splitting the year in half or even further. This creates the partitioning reduction in anonymity 
already mentioned. J * 

3.2.4 Early Termination of a Subscription 

Terminating a subscription early requires proving that the user is a particular subscriber, and returning a 
valid certificate. He will not get a new one; so, there is is no way for him to continue using the service. At this 
point he would presumably be entitled to a refund. Notice that early termination can even be customized 
for example, so that it is available only to customer's who have already subscribed for at least a year (Recall 
that a customer reveals his identity (or perhaps pseudonym) when he terminates early.) This removes one 
of the disadvantages of the third option for subscription expiration described above. 

We have been describing subscriber termination of a subscription. Vendor termination of a particular 
subscriber or group is far more difficult. (It may also be less important.) On our current approach the 
only way to terminate a subscriber is to change the service key(s) for the remainder of his subscription and 
require everyone else to reinitialize their certificates with the new key. This creates tremendous expense and 
inconvenience equivalent to what would be necessary if a service key were compromised. 

4 Applications of Unlinkable Serial Transactions 

Up till now we have been focused on basic subscription services as the application of unlinkable serial 
transactions. We now explore both expansions of the basic subscription application and other applications 
as well. As an example, we will set out our first variant on the basic protocol; however, we will simply 
describe later applications without giving full details on how to adapt the unlinkable serial transactions for 
them. Generally, it will be straightforward to see how to do so. 

4.1 Pay-per-use Within a Subscription 

We here describe a means to allow pay-per-use within a subscription. In order to facilitate this application 
we first describe a simple protocol that allows a vendor to mint his own simple iinonymous coins. It can thus 
be used whether or not a standard e-cash infrastructure is available. 

4.1.1 Unlinkable Token Protocol 

This protocol produces digital tokens that are to digital cash roughly as tokens iii a game arcade are to coins 
in tact it is an extreme simplification of some existing digital coin schemes. It might be applicable by itself to 
an on-hne game arcade jukebox, or movie service. However, our motivation is co use it with the unlinkable 
serial protocol to enable pay-per-use transactions in a subscription service. do not here discuss billine 
for tokens. We assume that the price of tokens was previously agreed. We also assume that since C has an 
account with V, a request for tokens implicitly authorizes a corresponding charge to C's account. 

Message 1 C -> V : [Request for tokens, C, h{j7{), .... h(N^) K - , 
ge 2 V -+C : [h[N^) K . x [h(m] K - , 
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In this protocol, the tokens are simply hashed nonces. Thus, as in the basic unlinkable serial protocol, 
the customer need not convince the vendor that the tokens are legitimate by, e.g., unblinding some number 
of submitted tokens before the vendor will sign the rest. All tokens have the same value, and Kz l is a key 
that the vendor uses only to sign tokens. Thus, V need not worry about what he is signing. To spend a 
token C sends it to V along with the nonce proving that it is his token. The vendor keeps track of spent 
tokens until they expire. The token signing key should have a published expiration time. All tokens should 
be used or exchanged by that time to avoid a need to update them. 



4.1.2 Unlinjkable Serial Protocol for Pay-per-use 



{Transaction} Kc v 



Message 1 


C-tV 


Message 2 


V ~>C 


Message 3 


V 


Message 4 


C-+V 


Message 5 


V -+c 


Message 6 


C-> V ; 



This is very similar to the basic protocol, except that we move the transartion (message 6 of the basic 
protocol) to occur before the delivery of a new certificate (messages 3, 4, and 5 of the basic protocol). 
Also, after the transaction completes and before a new certificate is signed the customer must pay for the 
transaction. The vendor sends him a billing message as the last message in the transaction. In place of 
message 4 the customer sends the blinded new certificate together with adequate payment. Payment can 
use tokens as just described or ordinary anonymous e-cash if that is available and preferred. In this way 
the vendor can be guaranteed that payment is received before he signs a new certificate for the customer' 
However this opens the possibility that a connection can break during a transaction before a new certificate 
» received by the customer. The customer still need not worry about revealing his identity to recover from 
a broken connection, but the vendor will be able to tie the reconnects attempt to the actual requested 
transition that occurred during the protocol run in which the connection broke. This may seem a slieht 
inelegance. For an application in which all transactions cost the same amount, transactions can be moved 
back to the end of the protocol, thus removing the inelegance. 

There are alternatives to this protocol. For example, certificates could include a credit balance, which 
must be periodically paid Payment would be made as a transaction. There is no harm in this transaction 
identifying the customer because it is-only.for-paymenUpurposes. The ffiaia limitation-on this approach is- 
that the credit balance is monotonically increasing. This may allow the vendor io link transactions and even 
to tie them to particular customers. 



4.2 Contracting Out Subscription Management 

Vendors may be interested in making available the anonymity afforded by our approach but may be less 
enthusiastic about the necessary overhead of maintaining a subscription, e.g., keeping track of spent certifi- 
cates. Along with the ordinary overhead of maintaining subscriptions, handling billing, etc., vendors may 
choose to hire out the management of subscriptions. It is straightforward to have the vendor simply forward 
transaction requests to a subscription management service, which then negotiates the business (certificate 
management) phase of the protocol with the customer. Once this is completed, the transaction phase can 
proceed between the vendor and the customer as usual. 
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4.3 Multivendor Packages and Discount Services 

For multivendor packages one can purchase what is effectively a book of coupons good at a variety of 
individual vendors. The way a coupon book would work is that vendors will authorize the package vendor 
to issue certificates for their services. Customers then engage in a protocol to obtain the basic certificates. 

If the coupons in the book are meant to be transferable, there is nothing more to the protocol If 
however, they are not, we must add a serial unlinkable feature to make sharing more cumbersome. In this 
case, when a customer submits a certificate for a service he must also submit a package certificate The 
package certificate must be updated as in the basic protocol. Service certificate are not to be updated- they 
can only be redeemed once. Vendors could all be authorized with the necessary key to update the package 
certificate. Alternatively, the processing of the certificates could be handled by the package issuer as in the 
contractmg-out application of unlinkable serial transactions just given. Notice that individual vendors need 
not be themselves capable of producing even coupons for their own services. It is enough that they can 
confirm the signatures associated with their services. 

Package books such as just described often offer discounts over vendors' b.isic rates as a sales incentive 
Another form of discount is one that is made available to members of some gro ap. Unlinkable serial transac- 
tions are useful for allowing someone to demonstrate such membership without revealing his or her identity 
Depending on the application, the various vendors offering discounts can sign new certificates or signing can 
be reserved for some central membership service in association with any request for discount at a vendor 
The latter case is again similar to the contracting-out application above. 



4.4 Membership and Voting 

The example just mentioned shows that the basic idea of unlinkable serial transactions can have application 
outside of commercial concerns. Specifically it should be useful for any application for which membership in 
some group must be shown, and where the inconvenience of sharing a serial certificate and the risk of audit 
outweighs the advantages of spoofing group membership. These might include some applications requiring 
proof of age or residency. ° 

As another example, consider a voter registration certificate. At voting time, the voter spends his 
certificate, is issued a new certificate, and votes. The new certificate is signed by a key that becomes valid 
after the current voting period expires, so voters can't vote twice. In this case, there is no possibility of 
sharing the certificate for a single election. If there is concern that formerly eligible voters continue to vote 
once their eligibility has expired, certificate keys could be subject to occasional expiry between elections 
Ineligible voters would then be eliminated since. t.h<>y. would be unable to register for new seed certificates 



5 Conclusion 



In this paper we have presented a protocol that can be used for unlinkable serial transactions. The protocol 
can be used in several types of commercial services, including unlimited use subscriptions and those incorpo- 
rating some kind of pay-per-use transaction. Unlinkable serial transactions can also be used for multivendor 
packages and d,scount services. And, they can be used for noncommercial applications such as voter regis- 
ration and proof of group membership. Although individuals are anonymous during each unlinkable serial 
transacts, they can be challenged to produce identification to prevent various kinds of fraud. 

Our approach relies on anonymous communication: there is no sense in using anonymous tokens, pseu- 
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donyms, etc if identities are revealed by the communications channel. For Web based commerce, the 
Anonymizer hides the identity of clients. Onion routing also provides anonymity, but in addition protects 
against traffic analysts and hides anonymity even if some of the nodes in the anonymity service are comprc- 

In this paper we have described means to prevent profiling by vendors. But, profiles may be beneficial 
to both the customer and vendor, e.g., for marketing purposes. Indeed, services such as Netangels and 
Firefly are aval able that build customer profiles for this purpose but promise to protect customer privacy It 
might be complicated to incorporate such trusted intermediaries with the protocols we have presented But 
decentraWg may ultimately provide better assurance to customers. Profiles can be collected locally at a 
user s workstation. This lets individuals control their own profiles. An individual could contact a marketer 
through an anonymous connection (cf. Section 2,2 and request advertisements suited to his profile. Once he 
closes the connection the marketer can no longer contact him. 

Our approach is based on primitives supporting e-cash but is designed to function in a credit card type 
commercial mfrastructure as well. By manipulating what must be trusted and by whom, as compared 
wit^their more common applications, we are also able to greatly simplify the use of such primitives in our 
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United States Bvtent and Trademark Office 



Commissioner for R&mf/rs 
Umteo States Patent and Trademark Office 

V^&HiHOTON, O.C. 20231 

www.usoiagcv 
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FILING RECEIPT 
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Washington, DC 20005 
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Receipt is acknowledged of this nonprovisional Patent Application. It will be ^idered in its °rder and you win 
be notified as to the results of the examination. Be sure to provide the U.S. APPLICATION NUMBER, FILING 
DATE NAME OF APPLICANT, and TITLE OF INVENTION when inquiring about this application. Fees 
transmitted by check or draft are subject to collection. Please verify the accuracy of the data presented on this 
receipt If an error is noted on this Filing Receipt, please write to the Office of Initial Patent 
Examination's Customer Service Center. Please provide a copy of this Filing Receipt with the changes 
noted thereon. If you received a "Notice to File Missing Parts" for this application, please submit any 
corrections to this Filing Receipt with your reply to the Notice. When the PTO processes the reply to 
the Notice, the PTO will generate another Filing Receipt incorporating the requested corrections {if 
appropriate). 
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